Allow configuring custom declarationPattens#79
Allow configuring custom declarationPattens#79Rutgerdj wants to merge 2 commits intoketupia:mainfrom
Conversation
With this addition its possible to configure custom patterns to match use statements in Ash related files. This can be used when you have a macro wrapping Ash.Resource for example.
There was a problem hiding this comment.
Pull request overview
Adds a new VS Code setting to let users define alternative use ... declaration patterns (e.g., use App.Resource) that should be treated as canonical Ash module declarations (e.g., Ash.Resource), improving module detection for wrapper/base modules.
Changes:
- Introduces
ashStudio.alternativeDeclarationPatternsconfiguration and threads it throughConfigurationManager→ModuleParser. - Extends
ModuleMatcherServiceto match configured alternative patterns (with de-duplication). - Adds unit tests for alternative pattern matching and updates the VS Code Jest mock to support configuration access.
Reviewed changes
Copilot reviewed 7 out of 7 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
| test/unit/parser/moduleMatcherService.test.ts | Adds tests covering standard + alternative declaration matching and de-duplication. |
| test/mocks/vscode.ts | Expands VS Code mock to support workspace.getConfiguration().get(...) for tests. |
| src/utils/config.ts | Adds typed access to alternativeDeclarationPatterns and includes it in getAll(). |
| src/types/extensionConfiguration.ts | Extends AshStudioConfig with alternativeDeclarationPatterns. |
| src/parser/moduleParser.ts | Reads alternativeDeclarationPatterns and passes them into module matching. |
| src/parser/moduleMatcherService.ts | Implements alternative pattern matching logic in identifyConfiguredModules. |
| package.json | Contributes the new ashStudio.alternativeDeclarationPatterns setting. |
You can also share your feedback on Copilot code review. Take the survey.
| // Get alternative declaration patterns from configuration | ||
| const alternativePatterns = ConfigurationManager.getInstance().get( | ||
| "alternativeDeclarationPatterns" | ||
| ); |
There was a problem hiding this comment.
Reading alternativeDeclarationPatterns via ConfigurationManager inside the parser couples src/parser/* to VS Code APIs indirectly (through vscode.workspace.getConfiguration), which reduces testability/reusability of the parser. Consider fetching this setting in the VS Code-facing layer (e.g. ParsedDataProvider) and passing it into moduleParser.parse(...) / identifyConfiguredModules(...) as an optional argument so the parser remains a pure logic layer.
| // Get alternative declaration patterns from configuration | ||
| const alternativePatterns = ConfigurationManager.getInstance().get( | ||
| "alternativeDeclarationPatterns" | ||
| ); |
There was a problem hiding this comment.
ModuleParser.parse() now depends on VS Code configuration (alternativeDeclarationPatterns). However, ParsedDataProvider caches parse results by document URI + version only, so changing this setting won’t invalidate the cache and the extension may keep showing stale sections/CodeLens/definitions until the document changes. Consider including the relevant config (or a hash/version of it) in the cache key, or clearing/reparsing on onDidChangeConfiguration for ashStudio.alternativeDeclarationPatterns.
| const matchesAlternative = Object.entries(alternativePatterns).some( | ||
| ([altPattern, standardPattern]) => | ||
| standardPattern === config.declarationPattern && | ||
| useDeclaration.includes(altPattern) | ||
| ); |
There was a problem hiding this comment.
Object.entries(alternativePatterns) is executed inside the nested loops, so it’s recomputed (and reallocated) for every (useDeclaration, config) pair. Precompute the entries once outside the loops, or invert to a Map<standardPattern, altPatterns[]> / Set to avoid O(UCA) scanning and repeated allocations during parsing.
This PR adds a configuration option to add extra patterns to match on for module declarations.
For example:
In Ash you can have a base module wrapping the
Ash.Resource:Your resource files would then look like this:
Which would not be detected by the extension (because its only looking for
use Ash.Resource.This PR adds a vscode configuration option to configure custom patterns to map to Ash modules:
Also added some tests to verify the logic works.
AI disclaimer
Part of this PR has been made possible by an LLM, but I've reviewed all the code myself